Portions of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention is related generally to what has become known in the computing arts as xe2x80x9cmiddlewarexe2x80x9d, and more particularly to a unique agent-adapter architecture used in systems and methods to integrate applications of the type normally deployed across a networked enterprise.
2. Statement of the Prior Art
According to one observer, if the lifeblood of today""s corporations is information, then their arteries are the xe2x80x9cinter-application interfacesxe2x80x9d that facilitate movement of data around the corporate enterprise. This has more recently become known as an xe2x80x9capplication networkxe2x80x9d.
For the typical organization, the application network has grown organically into a collection of ad hoc application integration programs. This menagerie has had a very serious impact on businesses as it increases the time for implementing new applications, prevents senior management from getting a clear picture of the business and, in short, clogs the corporate arteries. In spite of the fact that application integration has become crucial to a competitive corporation""s survival, it has nevertheless been acceptable in the prior art to handcraft or xe2x80x9chackxe2x80x9d custom code for such purposes at enormous long-term cost to the corporation. Long-term application integration decisions have, likewise, been made at the lowest possible levels based solely on individual project criteria. Because of the decidedly difficult nature of these problems, an effective enterprise application integration (EAI) solution has yet to be found.
The advent of the Internet, client/server computing, corporate mergers and acquisitions, globalization and business process re-engineering, have together forced corporate information technology (IT) departments to continually seek out new, and often manual, ways to make different systems talk to each otherxe2x80x94regardless of how old some of those systems may be. In the ensuing chaos, inadequate communications systems have had a debilitating effect on IT""s abilities to move as fast as the business needs it to.
Recent trends in IT have only exacerbated this problem by increasingxe2x80x94often by an order of magnitudexe2x80x94the amount of inter-application interfacing needed to support them. Most recently, enterprise applications have performed such functions as data warehousing and enterprise resource planning (ERP), and facilitated electronic commerce. A brief review of these three technologies would, therefore, be helpful in understanding the long-felt but as yet unresolved need for EAI.
Data warehousing techniques require large volumes of clean historical data that must be moved, on a regular basis, from many operational systems into the warehouse. Source data is usually structured for online transactional processing (OLTP), while the typical data warehouse also accommodates online analytical processing (OLAP) formats. Therefore, the source data must undergo extensive aggregation and reformatting as it is transferred to the warehouse.
A typical data warehouse according to the prior art is populated in four steps: (a) extracting the source data; (b) cleaning such extracted data; (c) aggregating the cleaned, extracted data in a number of dimensions; and (d) loading the warehouse. Each warehouse source requires the building of a specific data extraction, cleansing, aggregation, and load routine. Forrester Research estimates that the average large company has approximately four data warehouses. In two years, it is expected that this number will grow to six. The average amount of data contained in each warehouse is also expected to double in size in that same periodxe2x80x94from about 130 gigabytes to about 260 gigabytes.
The problems associated with such large amounts of data growing at an ever-increasing pace is exacerbated by the quality of source data. According to a study conducted by the META Group, typical data warehouses are being loaded today with as much as 20% poor quality data. That same study indicates that about 70% of its respondents used extraction, cleansing and loading processes that were coded by hand. With respect to the required aggregation processes, anecdotal evidence also reveals that as much as 50 hours of computer time may be required to complete this function alone. It is readily apparent that significant maintenance efforts would be involved with programs coded in such a manner.
On the other hand, typical ERP systems (such as the R/3 enterprise application developed by SAP AG of Walldorf, Germany, as well as those developed by PeopleSoft, Oracle, and Baan) are essentially large, integrated packaged applications that support core business functions, such as payroll, manufacturing, general ledger, and human resources. Large corporations find it particularly attractive to buy such software solutions from a single source, since it can cost between 10 to 20 times more to develop the same functionality in-house than to purchase it. Implementing an ERP system, however, can be an overwhelming process for a number of reasons.
First and foremost, the corporation is buying a product and not building a solution. This means that business units within the corporation must adapt to the product and how it works, not the other way around. Furthermore, today""s ERP systems cannot replace all of a corporation""s custom solutions. They must, therefore, communicate effectively with other legacy systems in place. Finally, it is not atypical for a corporation to employ more than one and completely different ERP system because a single vendor cannot usually meet every organizational need.
As a result, the options for getting data into and out of an ERP system preclude known approaches used for data warehousing. Each ERP system has a proprietary data model that is constantly being enhanced by its vendor. Writing extract or load routines that manipulate such models is not only complicated, but is also discouraged by the vendor since data validation and business rules inherent in the enterprise application are likely to be bypassed. Instead, ERPs require interaction at the business object level which deals with specific business entities such as general ledgers, budgets or accounts payable. Further details regarding implementation and use of one well-known and widely accepted ERP system may be found in Special Edition Using SAP R/3 (2d ed.), ISBN: 0-7897-1351-9, by Que Corporation (1997), the contents of which are incorporated herein by reference.
Electronic commerce in one form or another has been around for many years. In essence, it got its start with electronic data interchange (EDI). EDI permitted companies to communicate their purchase orders and invoices electronically, and continued to develop such that today""s companies use EDI for supply chain management. However, not until the more recent exploding use of online Internet websites to buy, sell, and even auction, items of interest has there been such a dire need for robust, effective EAI. See, e.g., U.S. Pat. No. 5,627,972.
Applications get developed in order to accomplish a specific business objective in a measured time frame. In a typical large organization, different teams of people using a wide assortment of operating systems, DBMSs and development tools develop hundreds of applications. In each case, the specific requirements are satisfied without regard for integration with any other applications.
Several powerful trends are driving the market for application integration. For example, significant developments in peer-to-peer networking and distributed processing have made it possible for businesses to better integrate their own functional departments as well as integrate with their partners and suppliers. The aforementioned Internet/xe2x80x9cintranetxe2x80x9d/xe2x80x9cextranetxe2x80x9d explosion is also fueling the demand for a new class of xe2x80x9chuman activexe2x80x9d applications that require integration with back-end legacy applications. Tremendous growth around the world in the adoption of enterprise application software packages (e.g., SAP R/3) also requires integration with back-end legacy applications. Finally, message oriented middleware (MOM)xe2x80x94products such as IBM""s MQSeries message queuing productxe2x80x94are becoming increasingly popular. Once customers realize the benefits of simple one-to-one application connectivity with MOM, their interest in many-to-many application integration increases significantly.
As the need for businesses to integrate grows, the number of IT dollars spent on integrating applications is increasing rapidly. According to various industry analysts, the need for xe2x80x9cmission criticalxe2x80x9d application integration will drive the combined market for MOM and xe2x80x9cmessage brokersxe2x80x9d to grow from $300 million in 1997 to over $700 million in 1999. According to an IBM survey of larger customers, nearly 70% of all code written today consists of interfaces, protocols and other procedures to establish linkages among various systems. Savvy IT executives can clearly see the dollar savings to be gained by acquiring off-the-shelf software to satisfy as much of this requirement as possible.
A message broker is a software hub that records and manages the contracts between publishers (i.e., senders) and subscribers (i.e., receivers) of messages. When a business event takes place, the application will publish the message(s) corresponding to that business event. The broker reviews its lists of subscriptions and activates delivery to each subscriber for that message type. Subscribers receive only the data to which they subscribe. A message published by one application can be subscribed to by multiple consumer applications. Similarly, a subscribing application can receive messages from multiple publishing applications.
Before applications can publish or subscribe to messages, they must register their interest with the broker. There are two basic and different methods for applications to register interest in a message typexe2x80x94subject-based addressing and message-content filtering. In subject-based addressing, the broker uses the subject to identify and route the message to all parties expressing interest in that subject. The subject is a word used to describe the contents of the message. For example, a subject of the name xe2x80x9chr. emp. new,xe2x80x9d could serve to distribute information (name, address, employee number, etc.) on a newly hired employee. In message content routing, on the other hand, subscriptions are made based on the contents of fields within the message. The subscriptions can be based upon the message type and/or specific selection criteria relative to a field within the message. For example, a loan approval application could subscribe to all purchase orders over $100,000.
One advantage to having two publish/subscribe paradigms is that the need to address messages to individual subscribing applications is avoided. Additionally, new subscribing applications can be added without any changes to the publishing application.
The typical publishing/subscribing broker uses a robust delivery vehicle for the actual distribution of messages between applications. As mission critical messages travel over a combination of external and internal networks, the systems software ensures that messages are never lost or duplicated in the event of network failures. More often than not, an asynchronous message delivery capability is provided which uses store-and-forward message queuing. In this paradigm, the queue-to-queue transfer takes place in pseudo-real time when the subscribing application is available. If the subscribing application is unavailable, the message is stored in a persistent queue for later delivery.
To be effective, the message delivery vehicle must include a business transaction coordination function. A business transaction is typically made up of several units of work. Each and every unit of work must complete in order for the transaction to occur. If even one unit of work fails, the whole transaction fails, and all completed units of work must then be reversed. These transactions are long running and require message-based updates to multiple databases. The business transaction coordination function provides this managerial support.
Two other important components are the rules-based engine and the data-transformation component. The business rules engine allows organizations to process messages based upon the unique requirements of their business. Typically, business rules engines provide a visual front end to avoid the need for programming in a procedural language. With this flexible approach, changes in business processes can be easily reflected in a modified rules configuration.
The data transformation component is used to develop application-specific adapters. These adapters convert the data formats and applications semantics from the sending application to the receiving application. There are many conversion requirements. They range from basic data transformation to resolving the incompatibilities that exist between the structure (syntax), meaning (semantics) and timing of the information that must be shared.
There are two main strategies for application adapters according to the prior art. One strategy is to convert all of the source data and synchronize (or xe2x80x9csyncxe2x80x9d) applications to a standard canonical form. Messages move from the source adapter to the sync adapter in this standard form. At the sync adapter, the messages are converted to the format of the sync application.
The second strategy for application adapters is to automatically convert the format and semantics from the sending application to the receiving application in one step, without any intermediate formats. In this approach, only one adapter is required for two applications to communicate with each other and it can be integrated with either of the applications.
The rules based engine and the data transformation component work together to reconcile the differences between applications. For example, before two applications can be integrated around an order, the business rules regarding the processing of orders must be defined within each system. Within Application xe2x80x9cA,xe2x80x9d an order might be comprised of a collection of data from multiple files and databases; whereas within Application xe2x80x9cB,xe2x80x9d an order might exist as an individual message nested within a larger file of business transactions. The difficult challenge is to resolve the incompatibilities between the structure of the data and the underlying content of an order as defined in each application.
There are a number of potential business benefits that message brokering provide. First of all is their ease of application integration. With message brokers, the integration of new applications with existing legacy or third-party applications can be performed in a shorter period of time. The integration can take place without any need for understanding the internal structure and design of each application. By focusing on the interface as messages, existing applications can be integrated with minimal disruption.
Support for electronic commerce is a second benefit that message brokering provides. As businesses begin to automate the supply chain of their vendors and partners, there is a need for their independent applications to communicate in a loosely coupled manner. This is precisely the essence and strength of message brokering. The message broker is completely congruent with the business need.
Last, but certainly not least, is message brokering""s support for continued heterogeneity. As new technology has evolved, new architectures have been developed and heterogeneity is increasing over time. A methodology such as message brokering is designed to accommodate today""s heterogeneous world and will be useful in the future. New, differing applications can be added over time as either publishers or subscribers, without any changes to the existing applications in the message broker.
In summary, message brokers have the potential to provide a least-common-denominator approach to integrating heterogeneous applications within an enterprise. Users can choose the best technology for each individual application whether JAVA, ACTIVE X, or CORBA, without concern for how that application will integrate with other applications in the enterprise. Message brokers thereby bridge the gap between applications of the future and the disparate and complex products and technologies that currently exist in today""s application catalogues.
While there are many benefits to adopting a message broker strategy, it must be kept in mind that there are also potential pitfalls. The very strengths of the message brokering in terms of its loose coupling flexibility, may also be its greatest weakness. The nature of message broker software, as noted above, is very generalized. Because it is designed to handle so many different conditions, testing all possible end-to-end code paths is an insurmountable task. When undetected bugs exist in the software, messages may be lost, delivered twice or delayed. The damage from such xe2x80x9caccidentsxe2x80x9d would be most keenly felt in enterprises where message brokers are used to integrate mission critical transaction processing applications. In financial transactions, for example, the delivery of one single message could be worth millions of dollars; while at the same time its non-delivery or delayed delivery could result in the loss of millions.
A second risk to a message broker implementation is the possibility that foreign applications will introduce unauthorized messages to the broker. This may also result in loss. For example, in the banking industry, counterfeit messages could be published and thereby cause the withdrawal or misappropriation of funds.
A third risk of message broker implementation is the classical, xe2x80x9csingle point of failure.xe2x80x9d Message brokers of the prior art are typically implemented in a xe2x80x9chub and spokexe2x80x9d architecture. This means that the majority of message traffic passes through a few central hubs. In the event of an outage or a physical disaster to one of those hubs, the mission critical operations of a business could come to a grinding halt.
Another problem with distributed hubs is the difficulty of managing the message broker complex. Because a message broker integrates so many different business applications into a few consolidated hubs, the talent and expertise required to manage and administer a message broker complex may be unattainable.
The potential risk exposure is large whenever technology is applied to mission critical transaction processing applications of an enterprise. One problem for message brokering is that it manipulates mission critical information. In relative terms, message brokering is fairly new. However, while some early adopter companies have had great success with the concept of message brokering, much more is needed before message brokers and EAI can enter the mainstream.
In the 1980""s software systems development concentrated on the ability of heterogeneous systems to communicate with each other. This was, in large part, due to the proliferation of proprietary communication protocols. Any newly developed system had to either comply with the application and data formats in place for the systems with which it wished to connect or communicate, or provide such application a specific translation. Accordingly, all software was customized to a greater or lesser degree.
In today""s rapidly changing environment, the concerted efforts of thousands of developers worldwide are focused on developing a system that satisfies the need for disparate applications to communicate with each other, without the necessity of embedding multiple, customized application-specific translation schemes. This as yet unfulfilled need is grounded in the imperative of the global economy.
Definitions
The following terms should be construed by those of ordinary skill in the art in accordance with their ordinary and accustomed meaning. To the extent the definitions, which appear herein below, differ from otherwise conventional definitions that may be known to those of ordinary skill in the art, it should be appreciated that such terms are hereinafter clearly set forth in such a manner to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term.
An xe2x80x9caccessorxe2x80x9d is a function specified in message definitions that the system uses to access data. Accessors identify the start and end of application data fields and system message elements, and remove or insert markers.
xe2x80x9cAdapter implementationsxe2x80x9d are code designed for a specific application that can either extract data and produce system messages, receive system messages and update data, or extract data in response to requests. When the user creates an adapter to use in an integration flow, the user builds it around an adapter implementation. System adapter implementations provide basic exception handling and can handle any message definition. The user can create the user""s own custom adapter implementations using the ADK.
xe2x80x9cAdaptersxe2x80x9d are integration flow objects that interact with enterprise applications to extract data or insert, update, or delete data.
The xe2x80x9cadministration consolexe2x80x9d is a graphical user interface (GUI) through which a system administrator configures and manages the system""s nodes and services.
xe2x80x9cAgent servicesxe2x80x9d provide system services to the adapters. An agent service is required on each host that runs an adapter.
A xe2x80x9cclasspathxe2x80x9d is an environmental variable that tells the Java virtual machine where to find the class libraries, including user-defined class libraries.
xe2x80x9cClientsxe2x80x9d are processes that remotely access computer server resources, such as compute power and large memory capacity. Typical system clients are the integration workbench 120 and the administration console 160.
A xe2x80x9cconnectionxe2x80x9d is an object that specifies startup or connection parameters for adapters. For example, an RDBMS connection specifies the JDBC driver, the URL of the database, the user name, and password.
xe2x80x9cConvertxe2x80x9d data is a process in which converters specified in message definitions convert an application""s native data types to the Java data types the system supports, and vice versa.
A xe2x80x9cconverterxe2x80x9d is a function specified in message definitions that the system uses to convert data. In such a manner, converters convert native data types to the Java data types that the system supports, and vice versa.
xe2x80x9cCustom adapter implementationsxe2x80x9d are code designed for a specific application that can either extract data and produce system messages, receive system messages and update data, or extract data in response to requests. Custom adapter implementations, created using the ADK, can connect to applications the system does not currently support.
A xe2x80x9cdefinition objectxe2x80x9d is an integration flow object that provides instructions for a process that the system is to implement.
xe2x80x9cDelimitersxe2x80x9d are tokens or markers that separate data fields in data from enterprise applications.
A xe2x80x9cdurable subscriptionxe2x80x9d is a property of the system""s message hubs that ensures the hub target objects receive all messages intended for them. If a target object becomes inactive, the system remembers those messages, which the target has received. When the target next becomes active, the system delivers messages the target has not yet received.
xe2x80x9cEnterprise applicationsxe2x80x9d are applications from which adapters extract data or to which adapters propagate data (e.g., SAP R/3 or MQSeries).
An xe2x80x9cEnterprise Messaging Service (EMS)xe2x80x9d according to the present invention is implemented using the Java Messaging Service (JMS). It enables the system to use multiple messaging modes, and supports message hubs and provides message persistence.
xe2x80x9cEnterprise Resource Planning (ERP)xe2x80x9d applications provide a turnkey solution (e.g., warehouse management, human resource management, and materials management) for common business problems. Examples of ERP products are SAP R/3, PeopleSoft, and Baan.
An xe2x80x9cEntireX Broker (ETB)xe2x80x9d is a cross-platform, message-oriented middleware according to the present invention, which links mainframe, Windows NT, and UNIX applications and components, Internet and intranet clients, and ActiveX- and Java-enabled workstations.
xe2x80x9cFilter definitionsxe2x80x9d are definition objects that specify criteria for screening messages out of integration flows.
A xe2x80x9cfunctions hostxe2x80x9d is a computing platform, such as a Windows NT server or workstation, or OS/390 mainframe.
xe2x80x9cHubsxe2x80x9d are integration flow objects that receive messages from source objects and hold the messages until the system delivers them to specified target objects. Hubs allow adapters and transformers to exchange messages asynchronously. They are also useful for concentrating message flows; multiple objects that produce the same kind of message can all send those messages to one message hub, which simplifies links among objects
An xe2x80x9cIDoc Extractorxe2x80x9d reads flat files produced by the SAP R/3 transaction WE63 to create implementation configurations and message definitions and stores them in the the system""s repository service.
xe2x80x9cImplementation settingsxe2x80x9d are runtime parameters for adapters (e.g., a polling interval).
An xe2x80x9cintegration flowxe2x80x9d is a series of linked system objects that move data from one or more enterprise applications to other enterprise applications.
xe2x80x9cIntegration objectsxe2x80x9d are integration flow objects, which send messages, receive messages, or both. See, e.g., adapters, hubs, and transformers.
An xe2x80x9cintegration workbenchxe2x80x9d is a graphical user interface (GUI) through which a user designs integration flows.
xe2x80x9cIntermediate documents (IDocs)xe2x80x9d is an SAP R/3 data format used by R/3 to exchange data with other R/3 systems and with other applications.
An xe2x80x9citem message elementxe2x80x9d is a message element that contains data. Items are the lowest level message elements in the hierarchy of the message definition. They cannot contain other message elements.
xe2x80x9cJava Database Connectivity (JDBC)xe2x80x9d is the Java API standard for SQL-based database access.
A xe2x80x9cJava Development Kit (JDK)xe2x80x9d is a software development environment for writing applications in the Java programming language.
xe2x80x9cJava Message Service (JMS)xe2x80x9d is a Java API specified by Sun Microsystems for messaging.
A xe2x80x9cJava Naming and Directory Interface (JNDI)xe2x80x9d is a set of APIs that assist with the interfacing to multiple naming and directory services.
xe2x80x9cJava Runtime Environment (JRE)xe2x80x9d is a subset of the Java Development Kit used to redistribute the runtime environment consisting of the Java virtual machine, Java core classes, and supporting files.
A xe2x80x9cJava virtual machine (JVM)xe2x80x9d is part of the Java Runtime Environment responsible for interpreting bytecodes.
xe2x80x9cLink markersxe2x80x9d are tokens or delimiters that separate data fields in data from enterprise applications.
A xe2x80x9cmessage definition categoryxe2x80x9d is a logical grouping for message definitions.
xe2x80x9cMessage definitionsxe2x80x9d are definition objects, which identify data the system is to extract from or propagate to an enterprise application. Message definitions also define how the system is to construct system messages from enterprise application data or create enterprise application data from system messages.
A xe2x80x9cmessage elementxe2x80x9d is a data object that makes up the message schema of a message definition. Message elements are arranged in a hierarchical structure, and can be sections, tables, or items.
xe2x80x9cMessage-Oriented Middleware (MOM)xe2x80x9d is software that uses messages to enable applications on the same or different platforms to communicate. Communications protocols are hidden from the applications. Examples of MOMs are MQSeries, EntireX Broker, and JMS.
xe2x80x9cMessage persistencexe2x80x9d relates to the storing of messages onto recoverable media. The system writes each message it delivers from one integration object to another to stable storage in a location the user specifies. If a system failure occurs while a message is in transit, the system can retrieve the message from storage when the system is restored and deliver the message to its targets.
A xe2x80x9cmessage schemaxe2x80x9d is that part of message definitions, which define how to structure a message. Message schemas can include section, table, and item message elements arranged in a hierarchical structure.
xe2x80x9cMonitor servicesxe2x80x9d store system runtime data, including system logs and statistics information.
A xe2x80x9cnodexe2x80x9d is a physical process (or Java virtual machine) that supports one or more system and application services.
xe2x80x9cNode hostsxe2x80x9d are software than enables the user to configure and run nodes on a machine. The user must install a node host on every machine, other than the node manager, that will host a node.
A xe2x80x9cnode managerxe2x80x9d is an interface through which nodes are managed. The interface allows the user to configure, start, pause, or stop a service. Node managers start and stop nodes as well. The node manager maintains the state of all of the services that are distributed to the nodes. In addition, the node manager maintains status information (e.g., current state or activity level) of a node or service.
xe2x80x9cPoint-to-point messagingxe2x80x9d is a messaging style for hubs in which the system delivers each message that arrives at the hub to a single hub target only (i.e., the first available target.
A xe2x80x9cprimary input messagexe2x80x9d is the main input data to the system transformation processes specified in transformer definitions. The system takes input data, transforms it, and creates output data needed by target applications.
xe2x80x9cPublish/subscribe messagingxe2x80x9d is a messaging style for hubs in which the system delivers each message that arrives at the hub to all hub targets.
A xe2x80x9creplierxe2x80x9d is a system object, such as a reply adapter, which provides data when transformers request it during the data transformation process.
xe2x80x9cReply adaptersxe2x80x9d are integration objects that reply to requests for data from other integration objects by extracting the data from applications and sending it to the requesting objects. Requesters send system messages containing data in key message elements, and the reply adapters insert data into related message elements and send the system messages back.
A xe2x80x9crepository servicexe2x80x9d is interfaced via Java Native Directory Interface, and stores configurations for all configured services and integration flow objects.
xe2x80x9cRouting servicesxe2x80x9d enable the system to direct messages through the system based on a message""s content, including filtering message content according to criteria the user define. The routing service supports filters.
A xe2x80x9csystem messagexe2x80x9d is a message, in platform-neutral format, that the system uses to move data from application to application.
xe2x80x9cSection message elementsxe2x80x9d are non-repeating groups of message elements that do not contain actual data. They contain other message elements that contain data (i.e., they contain items). Sections can contain any combination of message element types.
A xe2x80x9cservicexe2x80x9d is a process that provides product functionality. The system is made up of system, messaging, integration, and agent services.
xe2x80x9cSource adaptersxe2x80x9d are integration objects that extract data from enterprise applications, construct system messages from the data, and send the messages to other the system integration objects.
A xe2x80x9csource objectxe2x80x9d is an integration flow objects that provides messages to other objects. See, e.g., source adapters, transformers, and hubs.
xe2x80x9cSupporting input messagesxe2x80x9d are optional input data to the system transformation processes, as specified in transformer definitions. Transformation processes use supporting input message data to supplement primary input message data. The system takes input data, transforms it, and creates output data needed by target applications.
A xe2x80x9ctable message elementxe2x80x9d is a group of section message elements, called rows, that can repeat any number of times. Table elements do not contain actual data. Instead, they contain other message elements that contain data (i.e., they contain items). Tables can contain any combination of message element types.
xe2x80x9cTarget adaptersxe2x80x9d are integration objects that receive system messages from other integration objects, create application data from the system messages, and propagate the data to target applications.
A xe2x80x9ctarget integration objectxe2x80x9d is an integration flow object that receives messages from other objects. See, e.g., target adapters, transformers, and hubs.
xe2x80x9cTransaction Processing Monitor (TPM)xe2x80x9d is a software system designed to optimize use of computing resources, such as storage and applications, for many users.
To xe2x80x9ctransform dataxe2x80x9d is a process in which transformers modify data taken from one or more enterprise applications into data needed by other enterprise applications.
xe2x80x9cTransformation servicesxe2x80x9d enable the system to transform messages, including splitting messages, combining messages, and manipulating message data. The transformation dervice supports transformers.
A xe2x80x9ctransformation stepxe2x80x9d is a command that makes up the transformation process. Each step either reads input message data, transforms and maps input message data to output message definitions, or writes transformed data to output messages.
xe2x80x9cTransformer definitionsxe2x80x9d are definition objects that define how the system is to transform system messages extracted from one or more enterprise applications into system messages needed by other enterprise applications.
A xe2x80x9ctransformerxe2x80x9d is an integration object that implements transformer definitions. Transformers gather input messages from source integration objects, transform the content and format of the message data, and produce and send output messages to target integration objects.
xe2x80x9cUser interface services (UIS)xe2x80x9d provide the user interface facilities necessary to run the client components (i.e., the integration workbench 120 and the administration console 160).
Accordingly, it is a general object of the present invention to provide systems and methods for integrating enterprise applications, which at the same time provide comprehensive management, including centralized monitoring, operation and configuration.
It is a more specific object of the present invention to provide for improved message tracking and manipulation in such systems and methods.
Another object of the present invention is to provide enhanced security in such systems and methods, covering such aspects as authentication, authorization, privacy, non-repudiation, and auditing.
Still another object of the present invention is to provide systems and method for integrating enterprise applications that include means for disaster recovery, fail-safe rollover, message replay and dual-site logging.
It is also an overall object of the present invention to facilitate fast and simple integration of leading ERP applications, custom/legacy applications, packaged applications, and databases. More specifically, it is also an object of the present invention to reduce or substantially eliminate the need for the expensive custom coding that is traditionally required to integrate applications.
Another object of the present invention is to provide an EAI system with a distributed architecture that facilitates the long-term reliability, scalability, flexibility, and extensibility needed by today""s enterprises.
Still another object of the present invention is to provide an EAI system which increases an enterprise""s return on investment by enabling the enterprise to leverage its existing IT investments, increase its speed to market, implement solutions and realize benefits more quickly, and reduce its operational costs.
Yet another object of the present invention is to provide an EAI system which provides faster access to an enterprise""s customer and billing information so that the enterprise can service its customers more effectively and efficiently, creating stronger, more effective relationships.
A further object of the present invention is to provide an EAI system with many-to-many points of integration that substantially eliminates the concerns of conventional hub-and-spoke systems and their single-point-of-failure risks.
Still a further object of the present invention is to provide an EAI system, which simplifies the enterprise IT, architecture by providing a central point of integration for virtually all applications and platforms.
Yet a further object of the present invention is to provide an EAI system which provides efficient and cost effective information sharing.
The methods, apparatus, and articles of manufacture described herein will achieve the above and other objects, advantages, and novel features according to the present invention, while avoiding the problems described herein above.
In accordance with a first important aspect of the present invention, the method comprises computer-implemented means for passing messages between a first computer application and a second computer application. Such method generally includes the steps of: (a) providing a first message having a first data structure from the first computer application; (b) publishing the first message to obtain a first published message; (c) converting the first data structure of the first published message to a second data structure to obtain a second message; (d) publishing the second message to obtain a second published message; and (e) providing the second published message to the second computer application.
According to a second important aspect of the present invention, the apparatus comprises a system for integrating a plurality of computer applications. Such apparatus generally includes means for routing messages within the system; means for storing a plurality of data transformation configurations and a plurality of rules; means for applying the data transformation configurations to messages; means for applying the rules to messages; and means for routing messages between the means for routing messages within the system and the computer applications and having dedicated means for routing messages for respective computer applications.
Alternatively, the apparatus of the present invention comprises a system for integrating a plurality of computer applications. Such system generally includes an enterprise messaging system that passes messages between the computer applications; a database storage system, coupled to the enterprise messaging system, that stores a plurality of data transformation configurations and a plurality of rules; an integration service, also coupled to the enterprise messaging system and comprising a data transformation engine using the data transformation configurations stored in the database storage system and a rules evaluation engine using the rules stored in the database storage system; and a plurality of agent-adapters, further coupled to the enterprise messaging system with each agent-adapter coupled to a respective one of the computer applications to pass messages between the enterprise messaging system and the respective computer application.
In accordance with a third important aspect of the present invention, the article of manufacture comprises a computer-readable medium embodying code segments for integrating a plurality of computer applications. Such code segments generally include: (a) a first code segment for passing messages between the computer applications; (b) a second code segment for performing data transformation of messages; (c) a third code segment for applying rules to messages; and (d) a plurality of fourth code segments, each of which passes messages between respective computer applications and the first code segment.
The apparatus of the invention also includes a computer programmed with software to operate the computer in accordance with the invention. Non-limiting examples of a xe2x80x9ccomputerxe2x80x9d in this regard include: a general purpose computer; an interactive television; a hybrid combination of a general purpose computer and an interactive television; and any apparatus comprising a processor, memory, the capability to receive input, and the capability to generate output.
The article of manufacture of the invention comprises a computer-readable medium embodying code segments to control a computer to perform the invention. Non-limiting examples of a xe2x80x9ccomputer-readable mediumxe2x80x9d in this regard include: a magnetic hard disk; a floppy disk; an optical disk, such as a CD-ROM, a CD-R, a CD-RW, or one using DVD standards; a magnetic tape; a memory chip; a carrier wave used to carry computer-readable electronic data, such as those used in transmitting and receiving electronic mail or in accessing a network, such as the Internet or a local area network (xe2x80x9cLANxe2x80x9d); and any storage device used for storing data accessible by a computer. Non-limiting examples of xe2x80x9ccode segmentsxe2x80x9d include computer programs, instructions, objects, software, or any means for controlling a computer.
Other novel and equally important aspects of the present invention will become more apparent from a detailed description thereof, when considered in conjunction with the following drawings wherein: